|
Critical Component of the CMMS: The Repair Work Order |
By Christopher N. Winston, HSB Reliability Systems Group From the very start, the implementation of a computerized maintenance management system (CMMS) is a long and arduous process. One of the largest concerns is how to effectively get the correct data into the system in the first place, and then, how to get useful information out. What follows can provide a method to get better data into the CMMS with every work repair request. The yield is more and better data for analysis, which is the all important question in the long-term successful evaluation of the implementation—is this information tool providing useful information? There is no replacement for a good, integrated implementation plan that covers the setup of the database, training, data design and collection, etc. Consider this as an enhancement to be added to the existing plan. Repair data Basic repair data fields come in four categories:
Origination data includes the emergency flag, the original observer of the problem and how the person can be reached, the equipment experiencing the problem, and a problem description. This data must be obtained to effectively get labor and materials assigned to the job. Although it is most important to get all data consistently and correctly into each field, most problems occur at work order origination and multiply as the work order is processed. See accompanying section "Work Order Data Fields." The two most important fields at the origination of a repair are the equipment number and the problem description. The equipment number is needed to get the person to the correct equipment, as well as to insure charges are posted back to that piece of equipment for historical detail as well as summary analysis of its department, process, unit, etc. The importance of the problem description cannot be understated. Whenever a CMMS is implemented, every person who may originate a work order should be trained to call in (type in, write in, etc.) the problem description. This should include what was observed that prompted the call. Sample bad problem descriptions:
Bad problem descriptions do not provide enough descriptive data and they lead to bad descriptive results such as:
If the historical records within the system contain descriptions similar to these, plan to retrain everyone immediately and include a sample of these records to show how useful (or not) they are for historical analysis. More effective descriptions would be based on what the observer/originator of the problem sensed:
These are oversimplified examples, but a trained mechanic can identify a starting point and promote a response that is more descriptive of the cause. For historical purposes, this can be invaluable in looking at repetitive problems and working toward engineering them out of existence. Using a basic repair order Better understanding of why proper problem descriptions should be used is probably the biggest and most inexpensive way to make a major leap in repair data capture. A basic repair work order has room for free form text, but also specific codes that can be selected to help sanitize what is reported about the work, specifically to enhance analysis, expedite reporting, and, at the same time, not overburden the mechanic with paperwork. Results data should at a minimum include the skill/trade that completed the work, work time, a work description (what was done), materials used and/or costs, a cause code, downtime, and an assessment of the repair. The skill should have an associated wage (or wage plus burden) rate so that hours may be converted to costs for charging back to each piece of equipment, and the associated grouping codes (department, unit, etc.), when combined with the work time. The work description should explain the action taken on what part of the equipment. If recording downtime, it must be defined and all personnel must be familiar with how it is charged and used. The most common discrepancy comes when a machine is out of service for a maintenance reason during a nonoperating shift for that piece of equipment. Is it down? Get materials costs Materials used and their costs are helpful for keeping inventory up to date and charging materials to each piece of equipment. Having the material identified by its tracking number in the inventory control system (whether or not this is a module in the CMMS) is essential for documenting proper part usage and tracking and bill of material building. This is one of the first areas of potential interface when the nonproduct material is maintained by an organization/system outside of maintenance. This type of interface would allow documentation of the part number, and then the cost could be brought over from the parts inventory control system if it is not in the CMMS. This cost is especially important in light of the fact that many materials costs can exceed labor costs significantly, and both are necessary to properly assess the maintenance requirements and history of a given piece of equipment. Assess the repair, use codes Although additional comments about a job may not be entered, it is a good idea to get the mechanic’s assessment of the repair at least to the point where the repair is identified as "temporary" or not. A temporary repair is most often done to get the operation through the shift, and subsequently a relatively permanent repair is completed at a more convenient time. For each repair, an assessment should be provided by the mechanic. This comment may indicate the repair was temporary, and if so, it should be followed by a recommendation indicating what needs to be done to make it more permanent. Last, and not least, is some type of repair cause code. The reason a code is used instead of a description is to begin to categorize the repairs for easier analysis. Once statistical analysis is completed, the more significant individual items can be further analyzed by review and evaluation of their details. Codes in the CMMS represent a great potential advantage for accelerating recording of repairs, as well as their analysis, but can be extremely dangerous if overused. There should not be so many code fields, and/or codes per field, that it requires a separate page to list the possibilities, and someone must read through them for each repair. For example, a CMMS may contain fields for problem, failure, cause, root cause, solution, or action verb/noun combinations, etc. For each field, there may be 40 or 50 possibilities, and probably more. This just makes it take longer to complete the work order and often leads to more specific codes being added, thus making the recording process even more complicated. An important aspect to documenting work is simplifying the process. Use codes that are broad in nature, and relevant to the process environment wherever possible. An invaluable source of these codes is a review of historical activities that probably exist on manual records. Causes can be derived from work descriptions entered even if they are only to categorize parts problems from electrical, leaks, adjustments, etc. Multi-line work order The basic work order example is considered the workhorse for capturing planned and unplanned work, and provides areas to document extensions when the work is carried over for virtually any reason (scheduling, availability of materials, etc.). A multi-line work order that mechanics would have at the beginning of their shift is typically used to capture work that is often unplanned and would be completed during the shift. Items carried over are typically referenced from here and transferred to the basic work order form for future execution. The better and more consistently recording of repair activities is done, the greater potential for yielding greater and more specific information about the operation, in both qualitative and quantitative terms. The more quickly this can be done, the sooner actual activities will be reported into the CMMS, and a useful history will be built that can be more easily analyzed through statistical methods. Christopher N. Winston is an independent professional in the Detroit, MI, area contracted to HSB Reliability Systems Group, 1701 N. Beauregard St., Alexandria, VA 22311. He has more than 18 years’ CMMS implementation and business system analysis experience and has a bachelor of science degree in mechanical engineering.
|
Reference Source : http://www.mt-online.com/articles/0103_cmms_repairorder.cfm